IETF's RFC 5851 describes an Access Node Control Protocol (ANCP) by which an Access Node (AN), such as a Digital Subscriber Line Access Multiplexor (DSLAM), can communicate with a Network Access Server (NAS), such as a Broadband Remote Access Server (BRAS). This protocol is useful because at present ANs typically communicate with NASs only very indirectly (e.g. via an element manager which aggregates data from a large number of ANs and then passes this to a centralized management device which determines what actions (if any) should be taken by a corresponding NAS if the collected data from the AN indicates that such action should be taken. For example, if an AN connects to a Customer Premises Equipment (CPE) device at a much lower rate than normal, it may be necessary to quickly inform the corresponding NAS so that it can reduce the maximum rate at which downstream traffic (i.e. from the NAS to the AN) is allowed through the NAS towards the AN.
The indirect nature of the communication between ANs and corresponding NASs severely limits the amount of useful communication which can be carried out between an AN and it's corresponding NAS. ANCP solves this limitation by providing a protocol for direct communication between an AN and its corresponding NAS and thereby permits much more powerful cooperation between an AN and its corresponding NAS.
In view of the main perceived problem addressed by ANCP—namely the indirect nature of communications between an AN and its NAS—ANCP was deliberately designed to facilitate direct communications between an AN and its corresponding NAS. However, the present inventors have identified a flaw in the presently considered proposals for implementing ANCP between ANs and NASs which is that it will not scale well in situations where a single AN needs to communicate with a plurality of different NASs. Such a situation (i.e. where a single AN needs to communicate with a plurality of NASs) can occur where there is regulatory pressure on a network operator to permit plural competing organizations to have access to a single AN for their own separate commercial purposes. One particular problem is that ANCP supposes that a single continuously-open TCP connection will be set up between the AN and its (implicitly single) corresponding NAS. The most straightforward way of extending this approach to a case where an AN needs to communicate with multiple NASs would be to simply set up multiple continuously-open TCP connections—one with each respective NAS. However, this quickly becomes quite burdensome on the AN as the number of NAS's involved increases. Moreover, it requires placing intelligence in the AN to ascertain what information should be sent to what NAS, etc.
There is an alternative to using ANCP where the AN signals the current line speed by appending it to an existing connection establishment protocol—i.e. PPP or DHCP option 82. These are defined in Broadband Forum TR101, however they can only update the NAS when the connection is established, making them unsuitable in more dynamic environments.